At present, homes and offices have pluralities of so-called Consumer Electronics (hereinafter CE) devices like Residential Gateways (hereinafter RGW), TV, Personal Video Recorders, Media Centres, etc, which are enabled for connecting to a Local Area Network (hereinafter LAN). Other non-CE devices like washing machines, refrigerators, surveillance devices, etc, may also be enhanced to be LAN-attachable. A so-called home-LAN may thus include home CE devices and home non-CE devices attachable to said home-LAN, and which are accessible and controllable from a Control Point (hereinafter CP), the latter having data connectivity to said home-LAN. These CE and non-CE attachable devices are further referred to as LAN-attachable devices throughout the present specification.
In particular, a CP may be a cellular handset directly attached to the home-LAN, namely a so-called LAN-home-attached CP, such as those terminals with WLAN connectivity, or remotely attached to the home-LAN through a Public Data Network (hereinafter PDN), namely a so-called LAN-remote-attached CP.
A conventional way of remotely attaching a LAN-remote-attached CP to the home-LAN is by means of a Virtual Private Network (hereinafter VPN) established between a LAN-attachable device attached to the home-LAN, such as a RGW may be, and the LAN-remote-attached CP attached to a PDN. The VPN comprises a transparent end-to-end tunnel through the PDN, providing secure exchange of point-to-point frames between the LAN-attachable device and the LAN-remote-attached CP, said tunnel being used to exchange frames carrying control data blocks.
In this respect, and before exchanging commands with a LAN-attachable device, a CP needs to discover its existence and to identify that LAN-attachable device for addressing purposes. This task is usually performed by means of some domain-specific protocol, like UPnP, SIP, and other domotic control protocols. For example, US-2006/0133392 discloses the interworking between a SIP compliant terminal in an external network for remotely handling home devices through a gateway that includes a presence server for registering devices in a home network, devices which communicate with the gateway via a UPnP protocol. Also for example, US-2007/0143489 addresses the issue of interworking between a local area network where first appliances are connected via a UPnP protocol and a wide area network, such as an IMS network, where second appliances are connected via an IMS protocol. Moreover, each particular LAN-attachable device usually supports one particular domain-specific protocol with a particular identification procedure. Thus, any client application in a CP has to support a plurality of domain-specific protocols for an effective control of a variety of LAN-attachable devices in the home-LAN. Furthermore, especially where the CP is a LAN-remote-attached CP, said CP may also require different attach procedures to the home-LAN through the PDN depending on individual domain-specific protocols.
In summary, a LAN-remote-attached CP willing to remotely control multiple LAN-attachable devices conventionally needs the establishment of a VPN tunnel to the home-LAN and, then, using multiple domain-specific protocols, the LAN-remote-attached CP needs a discovery of the identifiers of those LAN-attachable devices. Moreover, establishing a transparent end-to-end VPN tunnel is a heavy task to perform by the tunnel ends, wherein encryption and/or authentication suites need to be negotiated and agreed, keys need to be exchanged, and protocol stacks need to be set up. This may result into a lengthy process, not suitable for an application requiring high responsiveness, such as for switching-on the heating system. In addition, using an end-to-end VPN tunnel prevents the operator of the PDN from providing value-added services to the user like, for example, programming some operations to be performed at certain periods, since the operator does not have access to the home-LAN and does not know how to identify each LAN-attachable device.